1. Visualizing Vehicles on the Internet
Visualizing products online, particularly vehicles and accessories on vehicles, is not new. A challenge is keeping up with the number and variety of possible vehicles and accessories, or parts or products, in the marketplace. For example, in 2008, General Motors alone offered 128 distinct vehicle models. Each one came in several colors. A configurator may show each of those vehicles from as many as eight (8) angles. That's well over 2300 unique views of a vehicle, and each one probably offers 15-20 configurable OE (Original Equipment, e.g., Ford) accessories. Managing the visualization of tens of thousands of parts on thousands of vehicle make, model, color, and view-angle combinations is a monumental task.
Accordingly, what is needed is a method for the rapid and organized production and deployment of vehicle configurators.
2. Conventional Techniques
Configurators can be found in the prior art. Generally, the functionality of the original configurators was relegated to self-contained run-time executables. Then the final published configurator file became an interactive ADOBE FLASH .swf file.
Lines of action script were hard-coded in the FLASH source file, and they essentially instructed that when a particular button is clicked, the file is to look for a movie clip named “X” and place it at these coordinates. There was vehicle-to-accessory logic beyond the simple action script of clicking one accessory to see it on the vehicle. All verification of specific fitment of an accessory to a vehicle was done as part of the hard-coding process and not based on any code-based logic. Conflict logic was based entirely on FLASH's inability to place two movie clips sharing the same instance name on the stage at the same time. This method of development and delivery was not scalable to the volume of vehicle-to-accessory information contained in the accessories catalog database.
In the prior art, development iterations began by attempting to bind configurator interaction to the actual accessories catalog database. To accomplish this and in addition to all accessories information already in the database, such as product name, application fitment, color, brand, pricing, description, product image, etc., additional data criteria were added: vehicle asset type (image, mask, or decal) and view.
The labels given to the three image types/assets in the vehicle asset type were Image, mask, and decal. Unpainted portions of the vehicle retained their color, while painted areas were set to a desaturated gray. Combining an Image and a mask resulted in a desaturated .png file with a fully transparent background. Combining a decal with an Image and a mask still retained an entirely desaturated .png file with a fully transparent background, as depicted by FIG. 4.
When the assets were layered on top of one another, a hexadecimal RGB value was fed into the desaturated mask layer and changed the color of the vehicle. Highlights and shadows remained sharp due to the decal layer, and the other elements of the vehicle (tires, glass, headlights, chrome, etc.) were unaffected as they were viewed through holes in both the mask layer and the decal layer.
Once a designer had a set of accessory image assets created and a portfolio of part images to place, the designer could build a source file in ADOBE PHOTOSHOP. Here, the designer could scale, rotate, skew, and place the part image so it would look realistic on the vehicle image, as depicted in FIG. 6. Once the designer placed the part image onto the vehicle, the designer could record the data points for the exact x/y positioning, scale, and/or angle of rotation, among other measurements, for that part on this view angle on this vehicle from the layered source file.
Next, via tedious hand-coded structured query language (SQL), a configurator could be built and deployed using t-matrices to place and position accessories on vehicles. This process was profoundly time-intensive driven by the database of available accessories. Consequently, if a part was discontinued and disappeared from the database, it also disappeared from the configurator.
Although the process had evolved to a point where the database communicated with the configurator, the labor-intensive production process (duplicating part assets, translating placement work to t-matrices, hand-coding SQL based on those translations) made rapid and organized deployments unfeasible. Thus, the solution to alleviate this labor-intensive production process was to develop “META,” a tool for the rapid development of vehicle-to-accessory visual configurators.
While certain aspects of conventional technologies have been discussed to facilitate disclosure of the invention, Applicants in no way disclaim these technical aspects, and it is contemplated that the claimed invention may encompass one or more of the conventional technical aspects discussed herein.
The present invention may address one or more of the problems and deficiencies of the prior art discussed above. However, it is contemplated that the invention may prove useful in addressing other problems and deficiencies in a number of technical areas. Therefore, the claimed invention should not necessarily be construed as limited to addressing any of the particular problems or deficiencies discussed herein.
In this specification, where a document, act or item of knowledge is referred to or discussed, this reference or discussion is not an admission that the document, act or item of knowledge or any combination thereof was at the priority date, publicly available, known to the public, part of common general knowledge, or otherwise constitutes prior art under the applicable statutory provisions; or is known to be relevant to an attempt to solve any problem with which this specification is concerned.